Subject: Adaptive pacing examples

From: [email-masked]
Date: Tue, 22 Feb 94 15:52:17 EST

Here are some example flows for the adaptive pacing proposal as it
currently stands.  I'm showing only one-way pacing for simplicity, but
of course both nodes can simultaneously act as pacing senders and
receivers.  Only two variables are required at the sender:
  PC (pacing count) - # frames the sender is currently authorized
                      to send before having to stop (cumulative)
  NWS (next window size) - the # additional frames that the receiver
                           would be granting if it sent a PRSP with
                           IWI=HWI=0.  That is, the base value to be
                           modified by IWI or HWI.

I'm showing the variable states BETWEEN frames.  PC=NWS is the condition
that trigger PREQ (there's no need to keep previous window info
explicitly).  Note that I should have added to the proposal that the
response to PREQ+RWI must include IWI or else it's meaningless.

If anyone wants to see "reset to 1" to think some more about the
decision we made, just ask.
Peter

EXAMPLE A:  Solicited, initial window size = 2
   Sender                Receiver
  PC   NWS
   2    2
           --PREQ-------->
   1    2
           -------------->
   0    2                   (sender has to wait here)
           <-PRSP---------
   2    2
           --PREQ-------->
   1    2
           <-PRSP+IWI-----  (things are ok, bump the next window)
   4    3                   (increment NWS before adding to PC)
           -------------->
   3    3
           --PREQ-------->  (first frame in window granted with IWI)
   2    3
           <-IPM-PRSP+HWI-  (halve the next window)
   3    1
           -------------->
   2    1
           -------------->
   1    1
           --PREQ-------->
   0    1

EXAMPLE B:  Unsolicited reset to 0, initial window size = 4
   Sender                Receiver
  PC   NWS
   4    4
           --PREQ-------->
   3    4                   (ok)
           <-PRSP---------
   7    4
           -------------->
   6    4                   (in trouble)
           <-IPM--RWI-----
   0    0
           --IPM-PREQ+RWI>  (required IPM, delimits the end of window)
   0    0                   (could wait a long time here)
           <-PRSP+IWI-----  (this is piggy-backed, more likely IPM;
   1    1                    I should have stated IWI is required here)
           --PREQ-------->
   0    1
           <-IPM-IWI------
   2    2                   (takes a while to recover from an RWI)

---

From: Gnanaprakasam Pandian <[email-masked]>
Date: Tue, 22 Feb 94 15:16:37 PST

thanks for your proposal with examples. They look great. 
Really helps to clarify the concept.

Please help clarify the following two questions. thanks.

> 
> To respond quickly to congestion, the pacing receiver may send an unsoli-
> cited "reset window" indication to the pacing sender.  This indication may
> be sent only as an IPM (not piggy-backed), with PRSP=0 and RWI=1.  Upon
						  ^^^^^^^^^^^^^^^^

QUESTION I
=========

Why not just keep PRSP = 1 for RWI, 
like the way it is done for IWI and HWI.
Although, the intention is to convey the unsolicited nature of this 
message, it kind of confuses the direction sense.

> receipt of this message, the sender immediately ends the current window and
> sets the next window size to 0.  The sender must immediately reflect the
> RWI bit along with PREQ in an IPM it sends to the receiver, both to
> solicit a new window and to allow the receiver to determine the end of
> the window outstanding at the time it sent the RWI.  The initial IPM with
> RWI resets a "PRSP owed" condition at both the pacing sender and receiver,
> but the receiver must still treat the entire currently granted window as
> outstanding until it receives PREQ+RWI back.
> 
> The pacing receiver may in fact send an IPM with RWI in place of a regular
> solicited pacing response, since it resets a "PRSP owed" condition.
> 
> 

>            --I( PREQ=1 ; PRSP=0 )-------->
>    3    4       			            (ok)
>            <-I( PREQ=0 ; PRSP=1 )---------
>    7    4
>            --I( PREQ=0 ; PRSP=0)--------------------------->
>    6    4                   			(in trouble)
>            <-IPM(PREQ=0 ; PRSP=0; RWI=1 )-----

                             receiver is congested and wants to stop
			     all the traffic from now on.

>    0    0
>            --IPM(PREQ=1 ; PRSP=0; RWI=1)----->(required IPM, 
						delimits the end of window)
>            <-I/IPM(PREQ=0 ; PRSP=1; IWI=1)-----  (this is piggy-backed, more likely IPM;
>            --I(PREQ=1 ; PRSP=0)-------->
>    0    1
>            <-IPM(PREQ=0 ; PRSP=1 ; IWI=1)------

QUESTION II
===========

> PC=NWS is the condition that trigger PREQ

I agree that this works as a good condition for most part.
Do the implementors have the freedom to make the decision on
when to ask for the next window size?

If the data rate is low, 
I would probably ask for the next window when I am just about running
out of current window rather than the above condition to put less
burden on the receiver.
(Example : Interactive traffic ; req/resp based protocol)

If the data rate is higher one could ask for more window size 
just when you are at the beginning of the current window.
(Example : File transfers with large SNA packet sizes over an IP tunnel with
small path discovery MTU; every SNA packet needs atleast so many IP buffers. )

Ideally should n't this be based on the rate of flow?

Also, if vendors implement  real buffer
reservation schemes and use the above condition to trigger
it wastes a lot of buffers at the receiver's side when they 
choose a large initial current window size.

-- 
G. Pandian           + Gnanaprakasam Pandian      +
Cisco Systems, Inc.  + Software Engineer          +           
1525 O'Brien Drive   + Phone : (415)688-7684      +
Menlo Park,          + FAX   : (415)688-8282      +
CA 94026             + E-mail: [email-masked] +

-- 
G. Pandian           + Gnanaprakasam Pandian      +
Cisco Systems, Inc.  + Software Engineer          +           
1525 O'Brien Drive   + Phone : (415)688-7684      +
Menlo Park,          + FAX   : (415)688-8282      +
CA 94026             + E-mail: [email-masked] +